The DBMS must fail to a known safe state for defined types of failures.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-52139	O112-C2-018100	SV-66355r1_rule		Medium

Description
Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Failure in a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Applications or systems that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption of mission/business processes. An example is a firewall that blocks all traffic rather than allowing all traffic when a firewall component fails. This prevents an attacker from forcing a failure of the system in order to obtain access. Databases must fail to a known consistent state. Transactions must be successfully completed or rolled back.

Description

Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Failure in a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Applications or systems that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption of mission/business processes. An example is a firewall that blocks all traffic rather than allowing all traffic when a firewall component fails. This prevents an attacker from forcing a failure of the system in order to obtain access. Databases must fail to a known consistent state. Transactions must be successfully completed or rolled back.

STIG	Date
Oracle Database 11.2g Security Technical Implementation Guide	2015-12-21

Details

Check Text ( C-54195r1_chk )
Check DBMS settings and vendor documentation to verify the DBMS properly handles transactions in the event of a system failure. If open transactions are not rolled back to a consistent state during system failure, this is a finding. Oracle creates what is known as archive logs. Archive logs contain information required to replay a transaction should something happen. The redo logs are also used to copy transactions or pieces of transactions. Check to see if the database is in archive log mode and if archive log mode is not enabled, this is a finding. Issue the following commands to check the status of archive log mode: $ sqlplus connect as sysdba --Check current archivelog mode in database SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination /home/oracle/app/oracle/arc2/ORCL Oldest online log sequence 433 Next log sequence to archive 435 Current log sequence 435

Check Text ( C-54195r1_chk )

Check DBMS settings and vendor documentation to verify the DBMS properly handles transactions in the event of a system failure. If open transactions are not rolled back to a consistent state during system failure, this is a finding.

Oracle creates what is known as archive logs. Archive logs contain information required to replay a transaction should something happen. The redo logs are also used to copy transactions or pieces of transactions. Check to see if the database is in archive log mode and if archive log mode is not enabled, this is a finding.

Issue the following commands to check the status of archive log mode:

$ sqlplus connect as sysdba --Check current archivelog mode in database

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /home/oracle/app/oracle/arc2/ORCL
Oldest online log sequence 433
Next log sequence to archive 435
Current log sequence 435

Fix Text (F-56953r1_fix)
Configure DBMS settings to properly handle transactions in the event of a system failure. DBMS failures must not leave transactions in an inconsistent state. If the database is not in archive log mode, issue the following commands to put the database in archive log mode. The database must be normally shutdown and restarted before the database can be placed in archive log mode. Issue the following commands to place the database in archive log mode: $ sqlplus connect as sysdba -- stop and dismount database and shutdown instance. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. Restart instance. SQL> startup mount; ORACLE instance started. Total System Global Area 1653518336 bytes Fixed Size 2228904 bytes Variable Size 1325403480 bytes Database Buffers 318767104 bytes Redo Buffers 7118848 bytes Database mounted. Enable ArchiveLog SQL> alter database archivelog; Database altered. -- Re-open database SQL> alter database open; Database altered. Issue the following command to see the new status: SQL> select log_mode from v$database; LOG_MODE ------------ ARCHIVELOG SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 294 Next log sequence to archive 296 Current log sequence 296 The database is now in archive log mode, and transactions are being recorded to either transport to another database or being re-applied if the database becomes corrupt and needs to be restored from the last backup. Use the redo logs to replay transactions not captured in the backup.

Fix Text (F-56953r1_fix)

Configure DBMS settings to properly handle transactions in the event of a system failure. DBMS failures must not leave transactions in an inconsistent state.

If the database is not in archive log mode, issue the following commands to put the database in archive log mode. The database must be normally shutdown and restarted before the database can be placed in archive log mode. Issue the following commands to place the database in archive log mode:

$ sqlplus connect as sysdba -- stop and dismount database and shutdown instance.

SQL> shutdown immediate;

Database closed.
Database dismounted.
ORACLE instance shut down.
Restart instance.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 1653518336 bytes
Fixed Size 2228904 bytes
Variable Size 1325403480 bytes
Database Buffers 318767104 bytes
Redo Buffers 7118848 bytes
Database mounted.
Enable ArchiveLog

SQL> alter database archivelog;

Database altered. -- Re-open database

SQL> alter database open;

Database altered.

Issue the following command to see the new status:

SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 294
Next log sequence to archive 296
Current log sequence 296

The database is now in archive log mode, and transactions are being recorded to either transport to another database or being re-applied if the database becomes corrupt and needs to be restored from the last backup. Use the redo logs to replay transactions not captured in the backup.